Перейти к основному содержимому

1.29. Бизнес

Всем

Бизнес

Бизнес получает деньги через продажи товаров и услуг, инвестиции, банковские кредиты, и, конечно, государство (через заказы и субсидии).

Бизнес обязан платить налоги с получаемой прибыли, а также другие обязательные платежи (НДС, страховые взносы и др.).

Бизнес сам по себе является частью экономической системы, но он может быть участником гражданского общества, если действует этично, участвует в социальных проектах, учитывает мнение потребителей и экологические стандарты. Сам по себе бизнес штука бессовестная, грязная и корыстная, граничащая с преступностью, однако государство осуществляет регулирование, а некоторые страны даже имеют особые, более строгие требования к участникам рынка. Всё это вынуждает бизнес действовать добросовестно, защищать конфиденциальность своих пользователей, поддерживать open-source, участвовать в благотворительности.

Однако бизнес, особенно крупный, может иметь свою собственную повестку, которая иногда противоречит интересам общества, может давить на законодателей (лоббирование), уклоняться от налогов и негативно влиять на окружающую среду.

В отличие от государственных информационных систем, корпоративные решения ориентированы на эффективность бизнеса, оптимизацию процессов, рост прибыли и удовлетворение потребностей клиентов.

Когда мы говорим о корпоративных системах, мы говорим о ситуации, когда инициатором является не государство или муниципалитет, а именно сама коммерческая (или некоммерческая) организация.


Как же создаются корпоративные системы?

  1. Выявление потребности. Процесс создания корпоративной системы начинается с понимания потребности бизнеса. Сначала выполняется бизнес-анализ текущих процессов, интервью с ключевыми пользователями и определение целей автоматизации.

Конечно, на практике может быть так, что владелец бизнеса просто скажет «хочу так-то», но для крупных корпораций существует целая иерархическая структура из бюрократических процедур, поэтому всё же этот анализ фактически существует.


  1. Формирование требований. Когда бизнес-анализ завершается, выполняется подготовка функциональных (что система должна уметь) и нефункциональных требований (производительность, безопасность, масштабируемость). Результатом будет являться набор документированных требований.

  1. Выбор модели разработки. Имея на руках лишь требования, приступить к разработке можно, но кто будет этим заниматься?

Здесь на выбор несколько моделей:

  • In-house (разработка собственной командой);
  • Аутсорсинг (привлечение сторонней компании);
  • Продуктовое ПО + доработка (customization);
  • Low-code / No-code платформы.

Компании не всегда имеют возможность выделить специалистов на разработку. Поэтому для выполнения работ/оказания услуг они обращаются к специализирующимся организациям - разработчикам (девелоперам), вендорам (продавцам коробочных решений, платформ) или интеграторам - компаниям, которые выполняют доработку продуктового ПО под нужды заказчика. К тому же, история знает много событий, когда компания амбициозно выполняет разработку своими силами, потом отстаёт от конкурентов и теряет прибыль, поэтому проще обратиться к мастерам своего дела.


  1. Проектирование архитектуры. В зависимости от выбранной модели разработки, выполняется выбор технологического стека, проектирование баз данных и дизайн интерфейсов. Коробочные решения часто предлагают готовую систему, которую нужно просто купить и установить, но на практике любой заказчик готов чуток доплатить, чтобы «подкрутить» под свои «хотелки».

  1. Разработка. Когда анализы выполнены и проекты готовы, выполняется разработка - написание кода, интеграция с другими системами, разработка API. Здесь всё зависит от решения, это может быть самым быстрым этапом, а может быть и затянутым производственным адом. Именно для скорости и плавности разработки и доставки решения, используют проверенные методологии. Сюда же можно включить и этап тестирования - зачастую компании-аутсорсеры сами и тестируют.

  1. Утверждение и согласование. После завершения разработки и тестирования, результаты необходимо проверить со стороны заказчика, согласовать с руководством, и учесть все юридические и регуляторные требования, при возникновении недочётов - исправить. Разработчики обычно дают гарантийный срок, в течение которого обязуются решить все вопросы, связанные с ошибками на стороне разработки.

Внедрение может быть пилотным (тестирование в одном подразделении перед массовым запуском), постепенным, параллельным, или даже мгновенным (полная замена старой системы). При внедрении, как и с государственными ИС, важно обучить сотрудников, подготовить документацию, техническую инфраструктуру, настроить все нужные интеграции и организовать управление изменениями.